Atty Docket No.: IDF 1761 
(4000-06400) 



REMARKS 

This application has been carefully considered in connection with the Examiner's 
Office Action dated February 23, 2007. 

By the Office Action of February 23, 2007, the Examiner rejected Claims 1-12 on 
various grounds discussed below. 

Summary of Rejections 

Claims 1-12 were pending at the time of the Office Action. 

Claims 1 and 2 were rejected under 35 U.S.C. § 1 12, second paragraph. 

Claims 1, 4, 6, 7, 9, 10 and 12 were rejected under 35 U.S.C. § 102(b) as being 
anticipated by Lenz, US Patent 6,029,196. 

Claims 2, 3, 5 and 11 were rejected under 35 U.S.C. §1 03(a) as being 
unpatentable over Lenz, US Patent 6,029,196 in view of Sandahl et al., US Patent 
6,098,098. 

Claim 8 has been rejected as being unpatentable over Lenz, U.S. Patent No. 
6,029,196 in view of Kaplan, et al., U.S. patent No. 6,141 ,339. 

Claims 2, 3, 5, 8 and 1 1 all depend from claims that have been shown to be 
patentable above and should now be allowable. 

Summary of Response 

Claims 1 and 2 are amended. 
Claims 3-10 remain in original format. 
Claims 11-12 have previously been presented. 
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The Applicants traverse the rejections and request reconsideration. Remarks 
and Arguments are provided below. 

Summary of Claims Pending 

Claims 1-12 are currently pending following this response. 

CLAIM REJECTIONS - 35 USC § 112 

Claims 1 and 2 have been rejected under 35 USC § 112, second paragraph, as 
being indefinite for failing to particularly point out and distinctly claim the subject matter 
which applicant regards as the invention. 

Claims 1 and 2 have been amended to make it clear that the method includes the 
step of "updating all parameters to those contained in the new configuration file." Claim 

1 covers such updating without rebooting. Claim 2 covers updating the parameter by 
rebooting the system. 

Applicants submit that the amended claims meet the requirements of 35 USC § 

112. 

As part of this rejection, the Examiner is interpreting the language of claims 1 and 

2 as ""updating of any information" to the client (i.e. "communication hub")." Applicants 
may disagree with the Examiner's interpretation to some extent. The Examiner's 
interpretation appears to be directed to transferring of information to the hub. The first 
step of claim 1 covers the transfer of a new configuration file to the customer premises 
telecommunications hub. The updating step is not directed to the transfer, but to an 
internal process in which the parameters that have already been transferred are actually 
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implemented or put into operation in the hub. These two steps are separate and distinct 
from one another. 

CLAIM REJECTIONS - 35 USC § 102 

Claims 1, 4, 6, 7, 9, 10 and 12 have been rejected as anticipated by Lenz US 
Patent 6,029,196. 

Claim 1: 

The Examiner asserts that Lenz teaches a method for updating configuration 
parameters in customer premises telecommunications hub comprising receiving in a 
customer premises telecommunications hub a new configuration file sent from a remote 
location. 

Lenz does not teach or suggest a customer premises telecommunications hub. 

A customer premises telecommunications hub is a specific type of equipment 
which is clearly defined in paragraph 5 of the present specification by incorporation by 
reference of US Patent 6,272,553. Lenz clearly discloses only computers and servers. 
A customer premises telecommunications hub contains many elements not found in 
typical personal computers. For example, it includes telephone interfaces for providing 
POTS, plain old telephone system, analog signals needed to operate telephone 
equipment at the customer premises. The customer premises telecommunications hub 
also provides interfaces for connecting personal computers to the internet. The 
personal computers, clients, of Lenz may be connected through the customer premises 
telecommunications hub to receive new files, including configuration files. But, the 
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personal computers are clearly a different piece of equipment than the customer 
premises telecommunications hub. 

Lenz at col. 5, lines 10-13, notes that its system allows users to move to different 
machines and always be able to log in as themselves. This function demonstrates an 
important difference between the personal computers, clients, taught by Lenz and a 
customer premises telecommunications hub. A customer premises telecommunications 
hub is a fixed piece of equipment installed on a customer premises to interface between 
various equipment on the customer premises, e.g. telephones and personal computers, 
and a telephone company central office. Users of a customer premises 
telecommunications hub do not log into the hub, they log in to a personal computer that 
may be connected to the hub. 

The Examiner asserts that Lenz teaches in a customer premises 
telecommunications hub, "identifying parameters in the new configuration file which are 
different than existing parameters stored in said customer premises telecommunications 
hub," citing col. 6, lines 28-29. 

Lenz does not teach or suggest any step of identifying parameters in a new file 
that are different from existing parameters stored in a customer premises 
telecommunications hub. The cited portion of Lenz is part of claim 1 and reads: 
"identifying the configuration file on said server associated with said client." 
This is part of a process for transferring a configuration file from a server to a client. 
The preceding step is sending a request from the client to the server for a configuration 
file. The following step is sending the identified file from the server to the client. This 
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has nothing to do with comparing a new configuration file to an old file to determine 
what differences exist. It discloses only a file transfer process. 

The Examiner asserts that Lenz teaches in a customer premises 
telecommunications hub, "checking the parameters which are different to determine 
whether they can be changed dynamically," citing col. 5, lines 38-41 and col. 3, lines 45- 
47. 

Since Lenz does not teach comparing a new file to an old file, it cannot teach 
checking the parameters that are different to determine whether they can be changed 
dynamically. Lenz does not teach or suggest making any determination of whether 
parameters may be changed dynamically. 

The first citation, col. 5, lines 38-41, is a description of steps 1004-1007 in Fig. 
10. In this process, the server requests setup parameters or file information from the 
client PC. Using information received from the client PC, the server sends an update of 
any information to the client if necessary (step 1006) and records any necessary 
information in the server (step 1007). This has to do only with how parameters are 
transferred between the client PC and the server. It has nothing to do with a 
determination of whether new parameters that have been transferred can be changed 
dynamically. 

The second citation, col. 3, lines 45-47, relates to Lightweight Directory Access 
Protocol (LDAP). It also discusses "set configuration data." It discusses a difference 
between dynamically setting such configuration data as opposed to statically setting 
such configuration data. This discussion clearly does not discuss the difference 
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between changing configuration parameters dynamically as opposed to changing them 
by rebooting the system. 

The Examiner asserts that Lenz teaches in a customer premises 
telecommunications hub, "if all parameters, which are different, can be dynamically 
changed, updating all the parameters to those contained in the new configuration file," 
citing col. 5, lines 41-44. 

As noted above, Lenz teaches nothing about distinguishing between parameters 
which can be changed dynamically and those that can be changed only by rebooting. 
Lenz could not teach a step of updating based on such distinction. The cited portion of 
Lenz discusses only the transfer of parameters from the server to the client PC. It has 
nothing to do with how the client PC changes the parameters internally. 

While Lenz provides a number of teachings concerning transferring parameters 
and files between a server and a client PC, Lenz does not provide any teachings about 
how the new parameters or files are actually installed or implemented in the client PC. 

The Applicants submit that claim 1 is clearly patentable over Lenz. Since claims 
2-8 depend from claim 1 , Applicants submit that claims 2-8 are also patentable over 
Lenz. 

Claim 4: 

The Examiner asserts that Lenz teaches a method according to claim 3 wherein: 
if the parameters, which are different, can be changed dynamically, said update module 
issues an update function call to each of the other functional modules, citing Fig. 11. 
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As noted above, Lenz teaches nothing about determining which, if any, new 
parameters can be changed dynamically as opposed to requiring a reboot. It can not 
condition issuance of an update function call based on a determination it does not 
make. 

Fig. 11 and its description discuss specifics of the process shown more generally 
in Fig. 9. That process starts with step 901, "Startup." Startup and reboot mean the 
same thing. The process of Fig. 1 1 is part of a reboot process. As taught in the present 
specification, it is known to update parameters as part of rebooting. The present 
invention is directed to avoiding rebooting if possible, by updating parameters 
dynamically, i.e. without rebooting. Lenz provides no teaching of dynamic updating. 

Applicants submit that claim 4 is clearly patentable over Lenz. 

Claim 6: 

The Examiner asserts that Lenz teaches a method according to claim 1 wherein: 
said step of updating parameters is performed when said customer premises 
telecommunications hub is in an idle state, citing col. 4, lines 40-42. 

Lenz teaches nothing about updating parameters when a client PC is in an idle 

state. 

The cited portion of Lenz reads: "To update all the user configurations, the 
administrator needs to edit only a single script file on the server and all of the clients 
automatically configure themselves." This has nothing to do with whether the clients 
update themselves in idle state. This does demonstrate that the teachings of Lenz 
relate to efficient transfer of configuration files to a plurality of client PCs. The present 
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invention relates to an improved method of updating the parameters within one 
customer premises telecommunications hub after a new configuration file has been 
transferred to the customer premises telecommunications hub. 

Applicants submit that claim 6 is clearly patentable over Lenz. 

Claim 9: 

The Examiner asserts that claim 9 teaches a customer premises 
telecommunications hub. 

As discussed above, Lenz teaches a plurality of client PCs, not a customer 
premises telecommunications hub. 

The Examiner asserts that Lenz, teaches a microprocessor having a plurality of 
functional modules ...each function module ... having a check function and an update 
function, citing Fig. 4. 

Lenz does not teach or suggest that its functional modules each include a check 
function and an update function. As described in the present specification, the check 
function is the process of checking a new parameter against an old parameter and 
determining whether the parameter is different and if so whether it can be changed 
dynamically or requires a reboot for changing. Lenz does not teach or suggest such a 
process. As noted above, the only process described by Lenz begins at startup, which 
is the same as a reboot. 

Applicants submit that claim 9 is clearly patentable over Lenz. 
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Claim 10: 

The Examiner asserts that Lenz teaches a system for dynamically updating 
configuration files in a customer premises telecommunications hub. 

As discussed above, Lenz teaches a plurality of client PCs, not a customer 
premises telecommunications hub. 

The Examiner asserts that Lenz teaches means for comparing parameters 
controlling operation of the customer premises telecommunications hub to parameters 
contained in the new configuration file and identifying parameters which are different, 
citing col. 5, lines 38-41 and col. 3, lines 45-47. 

Since Lenz does not teach comparing a new file to an old file, it cannot teach 
checking the parameters that are different to determine whether they can be changed 
dynamically. Lenz does not teach or suggest making any determination of whether 
parameters may be changed dynamically. 

The first citation, col. 5, lines 38-41, is a description of steps 1004-1007 in Fig. 
10. In this process, the server requests setup parameters or file information from the 
client PC. Using information received from the client PC, the server sends an update of 
any information to the client if necessary (step 1006) and records any necessary 
information in the server (step 1007). This has to do only with how parameters are 
transferred between the client PC and the server. It has nothing to do with a 
determination of whether new parameters that have been transferred can be changed 
dynamically. 

The second citation, col. 3, lines 45-47, relates to Lightweight Directory Access 
Protocol (LDAP). It also discusses "set configuration data." It discusses a difference 
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between dynamically setting such configuration data as opposed to statically setting 
such configuration data. This discussion clearly does not discuss the difference 
between changing configuration parameters dynamically as opposed to changing them 
by rebooting the system. 

The Examiner asserts that a Lenz teaches means for identifying parameters 
which can be changed dynamically, citing col. 6, lines 28-29. 

Lenz does not teach or suggest any step of identifying parameters which can be 
changed dynamically. The cited portion of Lenz is part of claim 1 and reads: "identifying 
the configuration file on said server associated with said client." 
This is part of a process for transferring a configuration file from a server to a client. 
The preceding step is sending a request from the client to the server for a configuration 
file. The following step is sending the identified file from the server to the client. This 
has nothing to do with identifying parameters which can be changed dynamically. 

The Examiner asserts that Lenz teaches means for, if all parameters, which are 
different, can be changed dynamically, dynamically updating parameters to those 
contained in the new configuration file, citing col. 5, lines 41-44. 

As noted above, Lenz teaches nothing about distinguishing between parameters 
which can be changed dynamically and those that can be changed only by rebooting. 
Lenz could not teach a step of updating based on such distinction. The cited portion of 
Lenz discusses only the transfer of parameters from the server to the client PC. It has 
nothing to do with how the client PC changes the parameters internally. 

While Lenz provides a number of teachings concerning transferring parameters 
and files between a server and a client PC, Lenz does not provide any teachings about 

15 

42097.01/4000.06400 



Atty Docket No.: IDF 1761 Patent 
(4000-06400) 

how the new parameters or files are actually installed or implemented in the client PC, 
much less in a customer premises telecommunications hub. 

Applicants submit that claim 10 is clearly patentable over Lenz. Since claims 1 1 
and 12 depend from claim 10, Applicants submit that claims 11 and 12 are also 
patentable over Lenz. 

CLAIM REJECTIONS - 35 USC § 103 

Claims 2, 3, 5 and 11 have been rejected as being unpatentable over Lenz, U.S. 
Patent No. 6,029,196 in view of Sandahl, et al., U.S. Patent No. 6,098,098. 

Claim 8 has been rejected as being unpatentable over Lenz, U.S. Patent No. 
6,029,196 in view of Kaplan, etal., U.S. patent No. 6,141,339. 

Claims 2, 3, 5, 8 and 11 all depend from claims that have been shown to be 
patentable above and should now be allowable. 

Kaplan et al., US Patent 6,141,339 

The Kaplan reference cited by the Examiner is assigned to the same assignee as the 
present application. It is directed to a telecommunication system which includes a 
residential hub, i.e. a customer premises telecommunications hub. This reference 
illustrates the point that a customer premises telecommunications hub is clearly different 
from a client PC. In Fig. 2 of Kaplan, the hub 204 is shown providing connections for 
two telephones 210, 212 and for two PCs 214, 216. The PCs are the clients that Lenz 
and other references discuss and are clearly different from a customer premises 
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Patent 



telecommunications hub. In the system of Lenz, the hub could be used as part of a 
communication system for transferring configuration files between a server and a 
plurality of clients. However, the hub and the clients are different pieces of equipment. 



The Commissioner is hereby authorized to charge payment of any further fees 
associated with any of the foregoing papers submitted herewith, or to credit any 
overpayment thereof, to Deposit Account No. 21-0765, Sprint. 

Applicants respectfully submit that the present application as amended is in 
condition for allowance. If the Examiner has any questions or comments or otherwise 
feels it would be helpful in expediting the application, he is encouraged to telephone the 
undersigned at (972) 731-2288. 



CONCLUSION 



Respectfully submitted, 



CONLEY ROSE, P.C. 



Date: ^1 




5700 Granite Parkway, Suite 330 
Piano, Texas 75024 
Telephone: (972)731-2288 

Facsimile: (972)731-2289 



Albert C. Metrailer 
Reg. No. 27,145 



ATTORNEY FOR APPLICANTS 
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